Handling Tapi Call Transfer Error Codes

[ktruk]

Hi, I am using the latest 5.2.5015 VG in a TAPI call transfer mode to do blindtransfers behind an ISDN PBX, but have some issues:

 

1. When the call is transferred to an idle extention, the transfer succeeds, but shortly after when VG initialises the line, a TAPI error is reported, but the line returns to a ready condition and will accept further calls.

 

2. If the transfer fails (ie: the ext is busy) a different TAPI error code is reported and the script is restarted from the beginning. If I add a fail (or success) path, it is ignored.

 

I wonder if it would be possible to add/fix the "{fail}" path or return the error code as an "{error xx}", so that the error could be acted upon to redirect the module path?

 

Here are some debug traces to illustrate what I mean:

 

141526.51  16 timer clear

141526.52  16 timer set 0.4  EV_TIMEOUT_READYTOBEGINTRANSFER

141526.83  16 timer fired EV_TIMEOUT_READYTOBEGINTRANSFER

141526.84  16 ScriptEventCode 9012 iLineState=1900

141526.84  16 LsXferStart EV_TIMEOUT_READYTOBEGINTRANSFER

141526.85  16 timer set 5  EV_TIMEOUT_ANNOUNCED_TRANSFER_ATTEMPT_TOOK_TOO_LONG

141526.86  16 state [TransferCall] Blind Transfer to 150 (TAPI)

141526.87  16 lineBlindTransfer(65828,150,0) in LsXferStart => 65572

141526.99  16 devstate NUMCALLS 0 0

141526.99  16 devstate OTHER 0 0

141527.76  16 tapi  Reply (LineEvReply) ok 65572 0 <transfer worked!!

141527.78  16 tapi  callstate start

141527.79  16 tapi  callstate DISCONNECTED 65828 1 0

141527.79  16 ScriptEventCode 9250 iLineState=1900

141527.80  16 LsXferStart EV_REMOTEPARTY_DISCONNECT

141527.81  16 rv    lg add [Hangup Time]{17/01/2006 14:15:27}

141527.82  16 state Hanging up call...

141527.83  16 RecSoundStop ok

141527.84  16 PlaySoundStop err=0

141527.85  16 timer set 2  EV_TIMEOUT_WAITFORIDLEAFTERLINEDROP

141527.86  16 fnHangupCall end

141527.87  16 devstate NUMCALLS 0 0

141527.88  16 devstate OTHER 0 0

141527.89  16 tapi  callstate start

141527.90  16 tapi  callstate IDLE 65828 0 0

141527.91  16 WorkingMode@Idle=

141527.92  16 timer clear

141527.93  16 timer set 1  EV_TIMEOUT_TIMETOREINITLINE

141527.94  16 devstate NUMCALLS 0 0

141527.95  16 devstate OTHER 0 0

141527.96  16 tapi  Reply (LineEvReply) err 65589 LINEERR_INVALCALLSTATE [8000001C]

141528.88  16 timer fired EV_TIMEOUT_TIMETOREINITLINE

141528.88  16 ScriptEventCode 9008 iLineState=900

141528.89  16 LsAwaitingCalls EV_TIMEOUT_TIMETOREINITLINE

141528.89  16      ReinitTelephony due to IDLE

141528.91  16 tapic lineDeallocateCall(MainCall:65828) 0

141528.93  16 lineOpen(16)=>

141528.93  16 state Waiting for a call...

141528.93  16 LineHandle=65657

141528.95  16 amchk set AMdet=False in Reinit@idle

141528.95  16 timer set 3  EV_TIMEOUT_ATERIDLE_ALLOWOUT

141529.62  0 dial  start any summary:|16:rdy=0|17:idx=0|18:idx=0|19:idx=0|20:idx=0|21:idx=0|22:idx=0|

141531.97  16 timer fired EV_TIMEOUT_ATERIDLE_ALLOWOUT

141531.98  16 ScriptEventCode 9013 iLineState=900

141532.73  0 dial  start any summary:|16:idx=0|17:idx=0|18:idx=0|19:idx=0|20:idx=0|21:idx=0|22:idx=0|

Looking at the above, I wonder if the line error is due to the line still ringing at the called extention? As mentioned, the transfer works, the error is just annoying, but can be ignored.

 

The next case is a failed transfer, followed by a restart of the whole script:

143824.63  16 timer clear

143824.68  16 RunModule PLAY end

143827.68  16 dtmf 1  (65744,49,2)

143827.71  16 ScriptEventCode 49 iLineState=1100

143827.77  16 LsPlayMsg 1

143827.82  16 PlaySoundStop err=0

143827.88  16 rv    lg add [Welcome]{1}

143827.93  16 timer clear

143827.99  16 timer set 0.4  EV_TIMEOUT_READYTOBEGINTRANSFER

143828.35  16 timer fired EV_TIMEOUT_READYTOBEGINTRANSFER

143828.37  16 ScriptEventCode 9012 iLineState=1900

143828.43  16 LsXferStart EV_TIMEOUT_READYTOBEGINTRANSFER

143828.48  16 timer set 5  EV_TIMEOUT_ANNOUNCED_TRANSFER_ATTEMPT_TOOK_TOO_LONG

143828.54  16 state [TransferCall] Blind Transfer to 150 (TAPI)

143828.60  16 lineBlindTransfer(65744,150,0) in LsXferStart => 66086

143828.73  16 devstate NUMCALLS 0 0

143828.76  16 devstate OTHER 0 0

143830.98  16 tapi  Reply (LineEvReply) err 66086 LINEERR_OPERATIONFAILED [80000048] <<<Line busy so get TAPI error, then next, script restarts...

143831.07  16 tapi  callstate start

143831.09  16 tapi  callstate CONNECTED 65744 1 0

143831.15  16 callstate CONNECTED 65744,1,0

143831.21  16 WorkingModeTAPI@Connected=BlindTransfer

143831.27  16 WorkingModeScript@Connected=

143831.32  16 Inband detection not enabled

143831.38  16 StartLoadedVgs at 17/01/2006 14:38:31, script interpretor VgMulti v5.2.5015 7

143831.43  16 rv    ns add [scriptsPath]{C:\Program Files\VoiceGuide\Scripts\Internet Portal\}

143831.49  16 rv    ns add [scriptPath]{C:\Program Files\VoiceGuide\Scripts\Internet Portal}

143831.55  16 rv    lg add [$RV_STARTTIME]{17/01/2006 14:38:31}

143831.60  16 rv    lg add [$RV_DEVICEID]{16}

143831.66  16 rv    lg add [$RV_CIDNAME]{}

143831.72  16 rv    ns add [PathApp]{C:\Program Files\VoiceGuide\}

143831.77  16 rv    lg add [$RV_CIDNUMBER]{030}

143831.83  16 rv    lg add [$RV_DNIS]{60}

143831.88  16 rv    lg add [DNIS]{60}

143831.94  16 devstate NUMCALLS 0 0

143832.00  16 devstate OTHER 0 0

143832.09  16 timer clear

143832.13  16 state [Welcome] Playing

 

So, just to recap, I want to avoid the script restart, and ideally, act on the fail/error code...

 

on {fail} goto [xxx]

 

or, take last part of error code, "80000048" as a hex word/byte?

 

on {error 48} goto [xxx]

 

Would it be possible to fix the above?

 

PS: I have to use the TAPI mode of call transfer, I cannot use "generate" mode.

[SupportTeam]

VG for Dialogic lets you act on these sort of errors, but the TAPI version of VG cannot trigger on error messages like the ones you mention.

1. When the call is transferred to an idle extention, the transfer succeeds, but shortly after when VG initialises the line, a TAPI error is reported, but the line returns to a ready condition and will accept further calls.

So does this error reported by the drives affect the operation in any way? From what I understand here the transfer has succeeded and then the line awaits a new call - so functionally all is OK?

2. If the transfer fails (ie: the ext is busy) a different TAPI error code is reported and the script is restarted from the beginning. If I add a fail (or success) path, it is ignored.

The TAPI driver here returns CONNECTED as well - which is what to VG indicates the start of a new call...

You could workaround this by setting a flag somewhere (Database?) that would indicate that the script is about to do a transfer and then at start of script check if the flag is set - if it is then play a 'transfer failed' message.

(flag would need to be cleared in an 'after hangup' script).

[ktruk]

Avoiding the script restart is the priority. Taking the caller back to the start of a 30 module script is a real ugly pain. I will try the flag idea, but have to say I don't like to put in code-frigs to work around product deficiencies, but I will give it a go and let you know if it works

 

Seems to me that hooking into the "on {fail}" path is the proper thing to do - and I would really prefer to do it this way, as its consistent with VoiceGuide operation generally.

 

I am not using Dialogic hardware at the moment for this app, so VG4Dialogic is not an option.

 

Thanks for the response.

[ktruk]

The TAPI driver here returns CONNECTED as well - which is what to VG indicates the start of a new call...

Actually, since you mentioned that the call had been connected, I think this is correct... since the PABX supports queuing on busy, I remember getting a queuing message briefly for about 2.5 seconds. Looking at the trace (2nd one listed above) there is about a 2.5 second delay between the lineBlindTransfer @ 143828.60 and the script restarting @ 143831.21. I guess the script restart is what reinits the line causing the queuing to be abandoned.

 

My utopian heaven would be to avoid the script restart after connecting and the line remains queued (perhaps taking an "on {fail}" or "on {success}" path) then I would finally get what I really want.

 

If the TAPI drivers return an "CONNECTED" state (or an LINEERR_* state), surely this is detectable within VG as part of the general path management?

 

The way this should work is pretty obvious, 1. do the transfer, 2. wait for/act upon Tapi event status message, take path (success/fail), allow script to take a success path to a module that waits for x seconds (queing time) or take a fail path to some other module that plays a message. Perhaps this is more of a "conferancing" operation? I know that TAPI supports conferancing, it it possible to have VG support this type of TAPI function in the call transfer module?

 

If an extra-payment custom mod is possible, let me know.

 

Just a couple of points on your previous response:

the TAPI version of VG cannot trigger on error messages like the ones you mention.

I find it really hard to appreciate why these states cannot be detected and acted upon, when you are reporting them in the trace!

So does this error reported by the drives affect the operation in any way?

No, it works, but the error condition is annoying, but I will live with it.

 

Finally, please read my previous posty regarding this issue above - many thanks again - tim.

[SupportTeam]

If the TAPI drivers return an "CONNECTED" state (or an LINEERR_* state), surely this is detectable within VG as part of the general path management?

If could be, but the TAPI version of VG currently does not pass the ERROR events and linestate events (CONNECTED etc) to the script interpreter, so the script interpreter cannot act on these (and does not even know they happened).

 

The way that VG (TAPI) acts upon receiving the CONNECTED event is built-in, resulting in a script being started as you can see on your system.

If an extra-payment custom mod is possible, let me know.

Guess it would be, but the modification would not be trivial. You may want to send an email to sales@voiceguide.com to see what the quote would be.

 

I find it really hard to appreciate why these states cannot be detected and acted upon, when you are reporting them in the trace!

Just not the way it's programmed right now. Possible to change it but the change may not be that easy...

[ktruk]

Firstly, having considered the situation, I really think that the VG script restarting is a bug in the call-transfer code. I can think of no reason why VG should restart the script as opposed to just hanging up or following the {fail} path.

 

You say that VG cannot respond to TAPI error or status conditions, but clearly it is responding, since VG restarts when it encounters this "error" and does not restart when it doesn't!! Therefore, something is happening here, wouldn't you agree?

 

I guess you are constrained by what the TapiWrap.ocx can or cannot do for you!

 

Can I clarify some specific details here, as it may help! Firstly, I am using the TAPI version of VG, AND using the TAPI transfer mode "LineBlindTransfer" - not the lineGenerate "Generate" call transfer method. Now, I asked for this TAPI transfer mode to be fixed/implemented last December that resulted in 5.2.5015 to be released, specifically to support this method of call transfer. I now suspect that possibly this TAPI modification may be slightly flawed, as the normal "generate" method (as far as I can recall, but am unable to test) does not restart the current script if a transfer fails. Because this code is "new" and perhaps a little untested, I think it is worth double checking it - the normal "generate" code is probably okay, its just my modified bit that needs looking at!

 

Perhaps you can refer this problem to the programmers for a second look, just in case something has been overlooked in the rush to provide a quick fix last month?

 

And finally, since the error effectively aborts a "successful" connection, perhaps the programmers could provide some form of "rough" bypass for the error, that either tricks VG into skipping the error or at least not abandoning the call/restarting. One idea may be putting a "on {timeout 0} goto [xxx]" (or similar) in the call transfer paths section so as soon as the transfer is initiated, the timeout path is taken regardless of the outcome of the transfer. (Perhaps force a "success" codition and take the success path?) What do you think?

 

Kindly talk it over with the programmers, together I hope we can come up with something - Thanks - Tim

 

PS: I will persevere with the restart flag as suggested, but so far, I haven't got this to work.